Jetfire Wiki
Jazz CMS
Debug
Jetfire Core
Jetfire Language
Jetfire Web Part
Library
Release Notes
Roles
States
Web Service
Workflow Administration
Quick Search
»
Advanced Search »
Back
First Class Constructs
Modified on 2012/01/20 20:23
by
John
Categorized as
Roles
,
States
=====Jetfire First Class Constructs===== [Jetfire Overview|Jetfire] at its heart is an OO language based [Jetfire vs net CSharp|heavily on C#] and Java. Jetfire does have a number of first class constructs that traditional object oriented languages (such as C#) do not have. These constructs provide Jetfire with its unique capabilities. They include: # '''Object and Class Persistence''': Jetfire [workflow|objects] and [workflow class|classes](code) are [Persistence|persistent]. They are automatically serialized and stored in a [workspace|workspace] or [namespace|namespace directory structure] on the [Server Nexus] when they are created or change. A [Server Nexus] (any Windows XP, Vista or Windows7 machine) is part of every Jetfire implementation. The server physical storage mechanism is typically a database or file system. Jetfire programs run until complete, which may be from days to months, surviving computer shutdowns and even crashes. A single instance of a [Workflow|Jetfire workflow] is even allowed to migrate to multiple computers. # '''Object Searching''': Searching for Jetfire objects, using a logical expression, is supported when the server nexus storage is configured to a Linq query-able mechanism(such as a SQL database). This allows applications, that consist of a very large number of objects stored in a database, to use searching to quickly provide a relevant set of objects. See [http://yourdotnetdesignteam.blogspot.com/2010/06/marthon-jetfire-application-example.html|blog article] # '''States''': Workflow classes can define a set of [states] allowing a workflow to be in one given state. Operations can be performed upon entering and leaving a state. Instance methods and properties can [dynamic access modifier|dynamically change to public or private] as the state of the workflow object changes. # '''Roles''': Jetfire provides role based security enforced by the server nexus. A Jetfire user can be assigned one or more [role|roles]. Methods, properties and workflows objects can have [dynamic access modifier|roles restricting usage and visibility] to Jetfire users without the appropriate role. When [workspace] is not visible the objects within are also hidden from the user. Jetfire uses roles internally to control all system functionality. # '''Multi-User''': Jetfire supports multiple simultaneous [user|users] with shared data. Each user, when active, has one more [client nexus|client nexuses] each containing objects. The client nexus contains only objects allowed by the user's [role|roles]. As data, both code and objects, is modified, added or deleted, each client nexus is automatically and transparently kept current. # '''Versioning''': Since code may need to change over time Jetfire has built-in [versioning] for classes. Classes, which are persistent objects within a Jetfire system, are automatically assigned a version number. Every time an class changes a new version is created. Objects created with an old version of code will continue execute the old code unless explicitly [WorkflowUpgrades|upgraded]. Jetfire has number of built-in safe guards to insure versioning integrity. # '''Audit Information''': Jetfire automatically and transparently collects information when objects and classes change, are created or deleted. The [audit information] collected is when, by whom, what and where. This information, stored as an 'Audit' workflow, can be programmatically retrieved via Jetfire code or by application code. # '''Change log''': (coming soon) A history log of all storage unit (objects and source code) changes can be optionally kept. This log can be used to identify exactly what changes were made or recover old versions of the data. # '''Dataflow Architecture''': Jetfire automatically updates properties as the values of fields and other properties change. Jetfire programmers do not need to write complicated event structures. Changes in Jetfire data can trigger standard .net event handlers. # '''Rules''': [Rules] make Jetfire a Business Rule Engine with forward chaining. Rules, in Jetfire, are methods are are automatically invoked by events. A rule method will test one or more conditions to determine if an action should be performed. Using the built-in versioning rules, and the policies they implement, can change quickly supporting 'grandfathering' or the new rules can be applied to the entire system. Rules can also be used to implement [http://en.wikipedia.org/wiki/Aspect-oriented_programming|Aspect-Oriented Programming] 'concerns' involving data. # '''Templates''': The [Templates|templating] feature of Jetfire supports the dynamic creation of code. This feature is significantly more advanced and easier to use than C# generics or C++ templates. # '''Multiple Language String Type''': The Jetfire 'string' type behaves identically to C# with the added feature that is supports multiple languages. A single string can contain an array of strings, where each array member represents a separate language. This supports features such as 'on the fly' changing of languages and hierarchical language translation. Hierarchical translation allows data to be viewed in a preferred language; however if the translation is not complete that parts of the data can be displayed in an alternate language or original language. It also supports 'mouse' over features where information can be displayed in an alternate language to aid in comprehension. # '''Void Safety''': Jetfire supports nulls; however provides '[void safety]' to prevent run time exceptions. =====Also see ===== [Jetfire Overview]
Meta Keywords:
Meta Description:
Change Comment:
ScrewTurn Wiki
version 3.0.4.560. Some of the icons created by
FamFamFam
.